The present invention relates to a testing system for testing a bus-based system.
Modern data processing systems are often built up of a plurality of individual components interconnected by means of one or more internal or external busses. The individual components can be, for example, central processing units (CPUs), memories, RAID subsystems, cache system, NIC cards, mass storage devices, etc. Different internal or external busses (in the following only referred to as busses) are generally (inter-)connected using one or more bus interfaces. Each bus interface (also called bridge) is coupled between (at least) two busses or between one bus and e.g. a CPU subsystem, and only such information which is intended to pass to the xe2x80x98other sidexe2x80x99 of the bus interface will be routed thereto. For that purpose, each bus interface xe2x80x9cknowsxe2x80x9d the address(es) of component(s) connected to the respective bus and/or the types of transfers it has to route through (in case of a PCI bus, this information is configuration cycles, special cycles or interrupt acknowledge cycles).
FIG. 1 depicts an example of a typical structure of a bus-based system. The system comprises three busses 10, 20 and 30. A bus interface 40 is coupled between bus 10 and bus 20, and a bus interface 50 is coupled between bus 20 and bus 30. As examples for individual components within the bus-based system are components 52, 54 and 56, each coupled to bus 10, components 60 and 62, each coupled to bus 20, and components 70 and 72, each coupled to bus 30.
In operation, when, for example, component 52 wants or is requested to write an information to component 72, this information is first placed on bus 10. Bus interface 40, which xe2x80x9cknowsxe2x80x9d that component 72 is coupled xe2x80x9csomehowxe2x80x9d to bus 20, routes that information to bus 20. Accordingly, bus interface 50, which xe2x80x9cknowsxe2x80x9d that the component 72 is coupled to bus 30, routes that information to the bus 30. The component 72, connected to bus 30, can eventually receive and accept that information. In another example, when, for example, component 60 wants or is requested to read from component 70, component 60 initiates a read signal onto the bus 20. The bus interface 40 knowing that the component 70 is not coupled to bus 10 will not route that read signal onto bus 10. However, the bus interface 50 knowing that the component 70 is coupled to bus 30 will route the read signal to bus 30, and component 70 will thus receive the read signal from the bus 30.
In order to test (also referred to as verifying or validating) the structure of the bus-based system and also the functionality and accuracy thereof, in particular of the bus interfaces, tests are normally executed in the xe2x80x9cnakedxe2x80x9d system generally without or only with a reduced number of components which could possibly be applied within the system. For this purpose the system will usually completely be xe2x80x98populatedxe2x80x99 with test devices, e.g. inserted into each free slot for inserting components, so that every slot and every bus can participate in testing the system.
A test system known in the art is employed by the Hewlett-Packard HP E2920 PCI series and the HP E2976A System validation package and uses test cards coupled to individual busses for validating the bus-based system. In the. example of FIG. 1, a testing card 80 might be coupled to the bus 10, a testing card 85 might be coupled to the bus 20, and a testing card 90 might be coupled to the bus 30. For validating the structure of the bus-based system, each testing card can write information to any other testing card and eventually read that information again from that other testing card. If the information read out from the other testing card equals the information written thereto, it can be assumed that the transmission of the information has been executed without faults and thus that the structure insofar is without faults.
FIG. 2 depicts the principle structure of the testing card 80, as an example for all of the testing cards 80, 85 or 90. The 80 comprises a memory 100, a sender (which might also be referred to as data source or initiator) 110, a receiver (which might also be referred to as data target or completer) 120, and a comparator 130. For writing information onto the bus 10, the sender 110 reads out that information from the memory 100 and puts it on the bus 10. It is clear that the external address and the internal address do not need to have any relationship with each other.
For comparing the result of a writing action onto another testing card (direction of arrow I in FIG. 2) e.g. on the testing card 85 (as indicated in FIG. 2 as a connection of the testing card 85 to the bus 10), the sender 110 initiates a reading action (direction of arrow II in FIG. 2) onto the other testing card 85. The read-out information from the testing card 85 will eventually be available on bus 10 and the receiver 120 will place that information to the comparator 130 which compares that information with the information corresponding to that address AD as stored in the memory 100.
Although the testing cards as depicted in FIG. 2 already lead to a sophisticated validation and verification of bus-based systems, some structural faults are only hardly detectable. Such a fault could be, for example, when data bits are exchanged during the data transfer, so that e.g. the data is changed first in the first direction and then back again in the second direction of the transfer. In that case, the receiver receives an information different from the initial information from the sender. However, the changed information will be changed again (and thus might be corrected) when it is read out, so that the information eventually received by sender again might xe2x80x98accidentallyxe2x80x99 equal the initial information. In such a case, the fault will not be detected. Another error that cannot be found is an addressing fault. If e.g. the address on bus 20 is slightly off the address on bus 10 because of address miscalculations within the bridge 40, the test device might still be able to receive the data and give it back again. In a real life system, wherein it is crucial that the data arrives correct and at the right place, this would cause an error.
It is an object of the present invention to further improve the validation of bus-based systems. The object is solved by the independent claims. Preferred embodiments are shown by the dependent claims.
In contrast to the conventional bi-directional data transmission scheme over the bus system for verifying purposes (as depicted by arrows I and II in FIG. 2), the invention is based on a concept of a unidirectional test data transmission over the bus-based system to be validated.
An inventive testing system provides a sending unit and a receiving unit, both coupled to or by at least one bus within the bus-based system. For testing (verification or validation) purposes, a data generator of the sending unit sends a specified information to the receiving unit. The receiving unit (directly) compares the received information sent from the sending unit with an information generated by a data generator of the receiving unit, whereby the data generation of the receiving unit is in a defined relationship with the data generation of the sending unit. Thus, the (test) information only has to travel once through the bus-based system and can be assessed and validated directly at and by the receiving unit.
The defined relationship between the data (pattern) generation of the sending unit and the receiving unit can be provided in different (deterministic) ways. One way could be an algorithmic relationship in a way that the receiving unit generates a data pattern making use of common information or knowledge that is available to both units. Thus, both units can test the other unit""s data pattern for correctness.
Preferably, the algorithmic relationship is based on the address of the receiving unit because this is an information known to both units. It is noted that in almost all bus-based systems, a clear relationship between address and data is guaranteed. Using the address (as a xe2x80x98seedxe2x80x99)for generating data patterns also avoids problems, if the transfer gets interrupted or partitioned by systems, such as a bus interface, between the two units. Bus systems usually only guarantee that a certain data pattern arrives at a certain address. However, it normally does not guarantee that the sequence of transfers to be done is identical to the sequence originally provided by the initiator. An example for the address-based pattern generation is e.g. that the data pattern already is the address itself of the receiving unit, or somehow derived therefrom (e.g. negated or circulated).
The algorithmic relationship allows the computation of a data pattern without using expensive memory and allows bypassing the size limitations that are automatically given by the use of internal memory. Another advantage is the ability to calculate the appropriate data pattern even if the transfer got interrupted or the sequence of transfers is mixed up by the connecting system. This can be made clear be the following example: A card 1 (sender) sends out data a package A to an address A1 and a package B to an address B1, both addresses are within the same bus-based system or device. The connecting bus interface (or bridge) slices the transfer A into subtransfers Aa and Ab towards the addresses A1 and A1b (which is A1 plus the length of Aa). In between these two transfers, the transfer B is put. Looking to two busses, the sequence of transfers on bus 1 is A and B, on bus 2 would, in our example, be Aa, B and Ab. The result is the same, but the sequence changed. The receiving card 2 (receiver) must now have a way of determining the expected data pattern out of the address this pattern is written to. This would not be possible if a fixed or otherwise generated sequence of data pattern is expected without taking the address information into account. The hardware effort of such a solution is very low, no extra connection (which would result in a complex network, if several test cards in various busses are used).
Another solution could be a (direct) connection between the respective data generators outside the bus-based system. Such a connection could be a (hardware) connection e.g. over respective connection lines or a wireless communication between the data generators.
A further solution could be provided by sending a pre-information from the sending unit to the receiving unit, instructing the receiving unit to generate a defined data pattern to be compared later on with a data pattern sent successively from the sending unit.
A further way to establish a defined relationship between the respective data generation could be by employing only predefined information so that the receiving unit knows in advance which data pattern will be sent from the sending unit. This can be accomplished e.g. by always using the same data pattern or by using different data patterns, but with a defined relationship between them (e.g. data pattern 1 at time 1, data pattern 2 at time 2 and so on). Preferably, time relationships could be determined using the time elapsed e.g. from a boot or power up action, or from the amount of data transferred.
Yet a further solution could be providing a defined timing relationship between the data generation of the respective units. This can be accomplished e.g. by a fixed relationship used for the timing of the generation of the data patterns, so that it is clear for the receiving unit at a certain point in time which data pattern is expected from the sending unit.
The receiving unit compares the received data pattern sent from the sending unit with the data pattern generated by the receiving unit. Thus, the receiving unit can draw back conclusions whether the routing of the information within the bus-based system works accurately, or, in other words, whether information gets to the correct address. Furthermore, data failures within the bus-based structure can be evaluated, or, in other words, it can be validated whether information is changed within a bus-based system.
By providing unidirectional flow of the test data, the invention significantly reduces the testing time, which is in particular paramount in bus-based systems with a plurality of different addresses and tests to be performed. The invention further allows reducing the effort required for the entire testing system. The time required for testing is not only shorter (because of the data transfer only in one direction), but also two tests can be executed concurrently i.e. data accuracy and correct addressing.
In an example, a system with altogether twenty possible slots for inserting cards is to be tested. Each test card for verifying the system should be able to test each other of remaining nineteen test cards. In a conventional application, each card would have to be equipped with internal memory of at least 1 Mbyte reserving 64 Kbytes exclusively for each test card. For high-speed memories, this would sum up with currently about $50 per test card. totaling to $1000 for the entire test system. This memory space will not be required in the test systems according to the invention (and the $1000 could be saved in that example), since the test pattern do not have to be stored but can be independently generated based on common knowledge between sender and receiver.
Another significant improvement provided by the invention is that an almost unlimited address range can be tested because a data generator can easily represent e.g. a 32 or even 64 bit address space with unique data patterns behind each address which would be either extremely expensive or impossible to do with conventional memory. Thus, address ranges can be tested which could not have been tested in an economically reasonable manner with the testing methods as known in the art.
It is clear that the terms sending or receiving unit do not necessarily have to relate to individual, physically separated units, but also applies to units wherein the sending and/or receiving functionality in accordance with the present invention is embodied as a sub-function or sub-module. The invention allows that a data generation and/or data comparison unit in accordance with the invention can be implemented into parts or components of the system, e.g. into a bus interface, bridge, special chip, or a chip set which might be coupled with a system memory. Thus, any interface between this part or component and another test receiver can be tested even if it is normally not accessible by an outside card. This way, testing is not limited to externally accessible slots e.g. for test cards, but these units with (built-in) testing capability in accordance with the invention can actively access other devices as if they were e.g. specific test cards (because their behavior, generating or accepting data patterns of a certain kind is known).
The term xe2x80x98busxe2x80x99 as used herein is to be understood in the broadest possible sense of word and might mean any kind of connection (wired or wireless; electrically, optically, magnetically, acousticallyxe2x80x94in any wavelength range) whether in its simplest form or as a more or less combination of a plurality of individually units, devices or components. Typical examples of busses could be AGP Bus, PCI Bus, PCI-X Bus, EISA Bus, ISA Bus, Firewire etc. In this sense, even a serial connection between two or more units could represent a xe2x80x98busxe2x80x99.